probably a way I can make this more compact and simpler

getAttributes sounds like a function in our typical parlance.

Can we call it attributeList or something that sounds like an object?

if the client isn't using these, can we just remove them?

I see they're part of the old UI that was commented out. I actually see no reason to keep this or any of the old code, especially since the JS functions that call these methods are gone, so they're totally dead code now.

sure I didn't know if we wanted to leave them up for any reason.

I think it'd be good to have some server-side validation here.

When saving a track, we hydrate a Pydantic Track with the json object. Normally this stuff would be enforced by a relational DB, but we don't have that, so Pydantic is the best we can really do.

See viame_detection.save_detection for an example of what I'm talking about. Should be a small change.

Also, I wonder if we should use a key signifier other than _id. That's a girder convention, and attribute is actually a girder model, but we aren't using it anymore. It confused me that there was still an _id.

What do you think about just id since this isn't a girder model and doesn't refer to one?

I don't know if we even need an id anymore. The tracks attributes and detection attributes are limited by their name (because of the CSV file). So really the identifier is a combination of the belongs and the name.

Sometimes no-param-reassign is a nuisance, but here I think it's protecting you. This function has an undocumented side-effect in that it sets the _id of the passed attribute. The caller relies on this behavior in an unclear way.

I actually see _id as unnecessary. It's synthesized from other properties and doesn't really provide any information. You could get rid of _id completely, have the map key be an implementation detail of useAttributes, and change the signature of deleteAttirbute to also accept the full object rather than an id.

I'm going to change the setAttribute and deleteAttribute to accept the full object. I started removing the _id from all Attributes and it just felt really wrong after a while computing the index each time I wanted to access it. So I think I'll rename the _id to key and prevent any reassignment.

I think it might be better to have setAttribute be able to accept an oldAttribute if one exists (for the instance of renaming the attribute and changing the index). So if a rename occurs it will delete the oldAttribute and replace it with the new one with the updated index. There are already client side checks to make sure you don't create a new attribute with the same key as existing ones.

I'm fine with key, but that leaves the side-effect issue. An option is to have setAttribute return a clone with key set such that using it requires localReactiveCopy.value = setAttribute(localReactiveCopy.value);?

The data Attribute isn't a direct reference, it's a new Attribute item built up of the changes and the oldAttribute is a reference to the item in the list and is only included if the user is updating an existing attribute.
The oldAttribute can be updated in the process by the name change causing a delete and refresh or by changing the type. When this occurs the item that had a reference to that as being open is already closed (AttributeEditor.vue) and as as the VueSet updates the attributes list it is then updated in the trackDetails.vue. The value isn't returned and instead relies on the reactivity of the attributes list provided to trackDetails.vue (Not ideal, but who is going to have an extremely large list on one dataset).

Please let me know if I'm missing something here and seeing stuff incorrectly.

I'm talking about the invocation from TrackDetailsPanel.vue, line 130.

      try {
        // before: saveData._id === ''
       await setAttribute({ data: saveData.data });
        // after: saveData._id === 'Belongs_NewName';
      } catch (err) {
        editingError.value = err.message;
      }

That _id change on saveData is a side-effect I'd like to avoid. It looks like you may have already changed this, so I'll review once you push.